Combining Monitoring with Run-Time Assertion Checking

According to a study in 2002 commisioned by a US Department, software bugs annually costs the US economy an estimated $59 billion. A more recent study in 2013 by Cambridge University estimated that the global cost has risen to $312 billion globally. There exists various ways to prevent, isolate and fix software bugs, ranging from lightweight methods that are (semi)-automatic, to heavyweight methods that require significant user interaction. Our own method described in this tutorial is based on automated run-time checking of a combination of protocoland data-oriented properties of object-oriented programs. 1 Run-Time Checking of Object-Oriented Programs Given a program and a specification, a run-time verifier inserts checks in the code that determine whether the specification is satisfied. The checks are triggered during an actual execution of the program. In contrast to static verification, where properties are checked with respect to all executions (possibly there are infinitely many), run-time checkers only consider a single execution of the program. There is a wide range of specification languages used in run-time verification. They can be partitioned into two categories: languages that focus on the control-flow (these approaches are also called “monitoring”), and those focussing on data-flow. As an example, one can use regular expressions to specify the order in which functions or methods in a program should be called [18]. Such specifications describe the control-flow of the program. Other formalisms for specifying controlflow are temporal logics, various kinds of automata and context-free grammars. For these formalisms, checking whether a given property holds of the current execution involves parsing a word (where the word is some representation of the trace of method calls in the current execution) in an automata. Generally only formalisms are chosen with a decidable parsing problem (in particular, this is the case for regular expressions, context-free grammars and most automata), so 1 http://web.archive.org/web/20090610052743/ http://www.nist.gov/public affairs/releases/n02-10.htm 2 http://www.prweb.com/releases/2013/1/prweb10298185.htm M. Bernardo et al. (Eds.): SFM 2014, LNCS 8483, pp. 217–262, 2014. c © Springer International Publishing Switzerland 2014 218 F.S. de Boer and S. de Gouw that everything can be automated. Specification languages for monitoring are discussed in more detail in the next section. Approaches that specify data-flow usually do so by annotating the source code with assertions: logical formulas that must be true whenever control passes them. The formulas constrain the values of the program variables. If assertions are expressed in first-order logic with arithmetic, it is in general undecidable due to unbounded quantification (i.e. ranging over an infinite number of values) whether the assertion is true, thus usually the assertions are restricted in some way. For instance, Java contains an assert-statement which restricts to quantifier-free formulas (i.e. Boolean expressions). Design by Contract [53] provides a systematic way of using assertions to specify classes, interfaces and methods with respectively class invariants and preand postconditions. It was first used in the programming language Eiffel, and subsequently has also been applied to many other programming languages. For example, JML [14] is one of the most popular specification languages for Java and supports Design by Contract. JML also supports unbounded quantification, though assertions containing unbounded quantifiers are not checked by the JML run-time assertion checker. While type checking for the most used imperative languages is done fully automatically at compile-time, run-time checking is done (also fully automatically) during execution, and properties are only checked for the current execution. This generally allows more expressive specifications compared to type checkers. Static verification cannot be automated. In particular, even if one restricts preand postconditions to just the formulas true and false, the resulting specification language is still undecidable (such assertions suffice to express the halting problem). Our own proposal is a method for run-time checking of object-oriented programs.We discuss below in more detail how run-time checking applies to the specific context of object-oriented programming, focussing first on single-threaded Java, and then describe an extension to concurrency. Two of the basic features of object-oriented programming are data abstraction and encapsulation. In the design of software, these features support the methodology of programming to interfaces [31]. This methodology allows the developer of client code to abstract from irrelevant implementation details. Combined with the design by contract principle [53], programming by interfaces is one of the main approaches to mastering the complexity of software today. One of the main formal behavioral interface specification languages for Java, the Java Modeling Language (JML) [14], is inherently state-based ; i.e., JML mainly provides support for the specification of classes in terms of their fields, including so-called model fields that represent certain aspects of the data structures underlying the implementation. JML does not provide explicit support for the specification of the interaction between objects, in contrast to other formalisms such as message sequence charts and UML sequence diagrams [23,41]. Combining Monitoring with Run-Time Assertion Checking 219 On the other hand, the very semantic foundations of object-oriented programming are defined in terms of sequences of messages. In [43], a fully abstract trace semantics for a core Java-like language is given, where traces (or communication histories) are (finite) sequences of messages. A fully abstract semantics in general captures the observable behavior abstracting from implementation details. Such an abstraction is required in for example a proper semantic definition of behavioral subtyping as is illustrated by the fragile base class problem [54]: According to the initial/final state semantics the class B (Figure 1) and its revised version in Figure 2 below are behaviorally equivalent.